There are some stuff left here.

This first implementation has the attributes above the block (which also feels natural to me), but looking at what others have done/thinks about this, the common thing is to put it below, e.g.:

> foo
> bar
{.myclass}

vs

{.myclass}
> foo
> bar

• https://kramdown.gettalong.org/syntax.html#attribute-list-definitions
• Commonmark draft: https://mb21.github.io/stmd/spec.html#attributes

@yuin do you have any thoughts on this (also: re. my implementation in this PR)?

/cc @jmooring

IMHO, There are no standards for attributes. pandoc has the attributes above the block.
Your implementation is no problem. But It may be hard to follow this rule for some elements (i.e. table cells). So attributes for these elements are hard to implement as extensions...

@yuin thanks, I (and I suspect most people) do not care about table cells ... I think the test cases I've added would make most people happy.

So, there are more to this syntax than the below, but what I can not make up my mind about is whether to place the attribute lists below or above the Markdown blocks. The CommonMark people have discussed this for years. There is some context above, but I'm making this a simple "above" or "below":

{.myclass}
> foo
> bar

Or

> foo
> bar
{.myclass}

• https://kramdown.gettalong.org/syntax.html#attribute-list-definitions
• Commonmark draft: https://mb21.github.io/stmd/spec.html#attributes

Would it not make sense to follow the Commonmark and the Kramdown spec (i.e. after) to allow for everything to play well?

@bep Is this something that could be configurable?

Instead of above or below, think in terms of before or after. The existing implementation of heading attributes requires the attribute to be placed after the heading.

@bep Is this something that could be configurable?

Could, yes -- but ... that is a bad idea as it ties the content to the configuration making it very unportable.

The current implementation in this PR allows both before/after, but I also think that is a bad idea.

I think I agree with @jmooring -- and after is the closest we come to a "standard" at the moment.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.